|
|
| Author |
Thread Statistics | Show CCP posts - 0 post(s) |
darius mclever
   |
Posted - 2010.10.21 23:37:00 -
[1]
oauth support for the API
advantages:
- CCP could differ different API using apps easily.
- might requires that apps need to be registered with CCP
- having credential per app becomes possible.
- revoking the credentials for one app doesnt render all other apps useless.
- it is less likely that CCP sees lots of api access with outdated keys. still possible though
- yes you could also see it as a disadvantage that you have to revoke multiple credentials to get rid of all apps. but i think the advantages make up for that.
- open standard
- you could think about some kind of "persona" support.
- predefined personas would be "limited" and "full" to easily map the current access profiles
- creating your own personas with different access profiles
- market app can only see your transactions and wallet status
- killboard can only get corp killmails but not your market stuff.
disadvantages
- if oauth becomes the exclusive, it would require all app authors to add oauth support to their apps
- though for most languages you have libraries out there that handle the tricky bits for you.
- oauth spec recommends HTTPS for access. currently the EVE API is using plain HTTP, so a proper implementation might mean more load for CCP servers because of encryption.
Johnathan Roark: why do you think oauth would be less secure? properly implemented it is way more secure than the current pattern, where i just need to sniff your userid/apikey and i can reuse it for ever/or until you revoke the key and create a new one.
|
darius mclever
|
Posted - 2010.10.23 15:00:00 -
[2]
 Originally by: Tonto Auri
Totally forgot (and wtf noone mentioned?) HTTP response codes to indicate API response status.
It's "a bit" off to have HTTP 200 OK containing actual error message.
+1
|
darius mclever
|
Posted - 2010.10.25 22:02:00 -
[3]
Originally by: Hel O'Ween
Originally by: Tonto Auri
Pediwikia isn't the best place to read about technical specifications. It only good at providing non-technical information for non-technical (i.e. informative) purposes.
I don't care to read further about technical details if Twitter has its hands in the design.
oauth is an open standard. twitter just happens to use it.
Quote:
Quote:
Totally forgot (and wtf noone mentioned?) HTTP response codes to indicate API response status.
It's "a bit" off to have HTTP 200 OK containing actual error message.
That depends from which angle you're looking at it. 200 OK makes sense, because the *web* server was technically able to web serve your request. That the database backend might not be able to answer your request should be of no concern for the web server.
I can see pros and cons for both positions as long as the behavior is consistent.
actually ... HTTP is just a medium. you are speaking to the application over the protocol, so if e.g. the old cached information is still correct it could give me a 304 return code instead of http 200 and some weird error in the xml.
or if my account ran out, it could answer every request with 402 payment required. ;) (my favorite return code. )
that said ... encoding the error into the body and having the client to guess from it doesnt make sense for every state that is handled in the http protocol.
|
darius mclever
|
Posted - 2010.10.26 19:36:00 -
[4]
Originally by: Hel O'Ween
Originally by: darius mclever
oauth is an open standard. twitter just happens to use it.
Twitter *drafted* the standard (and uses it, of course). *Big* difference for me. But my personal dislike of social web services is out of scope of this discussion.
Yes one employee of Twitter was in the initial group that discussed the oauth standard. but what about the 2 other guys?
anyway, i forgot one important thing:
with oauth you could use (api|www).eveonline.com to authenticate users on 3rd party sites. (e.g. like twitter and others allow), that would save 3rd party sites implementing their own authentication scheme, especially when the sites later use informations from the API anyway.
|
|
|
| |
|